Fix duplicate OAuth code exchange causing invalid_grant crashes (MAILSPRING-CLIENT-37) - #2792

Summary

Fixes MAILSPRING-CLIENT-37 — 111 events / 51 users, unresolved.

Sentry error:

Error: OAuth Code exchange returned 400 Bad Request: {"error":"invalid_grant","error_description":"AADSTS9002313: Invalid request. Request is malformed or invalid. ..."}

Stacktrace: oauth-signin-page.js:100 _onReceivedCode → onboarding-helpers.js:210 buildMicrosoftAccountFromAuthResponse → onboarding-helpers.js:44 fetchPostWithFormBody

Root cause

OAuthSignInPage (used for Gmail, Office 365, and Outlook sign-in) starts a local http.createServer in componentDidMount to receive the OAuth redirect. Its request handler called this._onReceivedCode(code) for every incoming request that carried a code query parameter, with no check for whether a code had already been received and processed:

this._server = http.createServer((request, response) => {
  if (!this._mounted) return;
  const code = extractOAuthCodeFromUrl(request.url);
  if (code) {
    this._onReceivedCode(code);   // <-- runs on every hit, not just the first
    response.writeHead(302, { Location: 'https://id.getmailspring.com/oauth/finished' });
    response.end();
  }
  ...
});

OAuth authorization codes are single-use. _onReceivedCode triggers a code exchange that can take several seconds (token exchange + Graph profile fetch + IMAP/SMTP connection test in finalizeAndValidateAccount), and during that window a second request to the same callback URL is plausible — a browser retry, a security product prefetching/scanning the redirect link, or a back/forward replay of history. When that happens, the second fetchPostWithFormBody call resends the already-consumed code, and Microsoft's identity platform rejects it with invalid_grant / AADSTS9002313 ("Invalid request. Request is malformed or invalid"), which is exactly the error reaching Sentry. The same code path is shared by Gmail and Outlook, so the same failure mode applies there too (surfacing as the provider-specific equivalent of a reused-code error).

I verified there's no other issue at play here: the redirect_uri sent during the initial auth request and the token exchange match exactly, and the PKCE code_verifier/code_challenge pair is generated once and stays consistent between the two requests. The systemic, repeated nature of the error (111 occurrences across 51 distinct users) also fits a structural double-invocation bug better than users simply being slow to complete the flow.

Fix

Add a _codeReceived guard so only the first request carrying a code triggers _onReceivedCode(). Later requests (e.g. a duplicate hit) still get the same 302 redirect response, so the browser experience is unaffected — we just stop re-submitting an already-consumed code to the provider.

Test plan

• Read through the full onboarding OAuth flow (oauth-signin-page.tsx, onboarding-helpers.ts) to confirm redirect_uri and PKCE code_verifier/code_challenge are consistent between the auth request and token exchange, ruling those out as the cause.
• Confirmed OAuthSignInPage is shared by Gmail, Office 365, and Outlook sign-in (page-account-settings-gmail.tsx, page-account-settings-o365.tsx, page-account-settings-outlook.tsx), so the fix covers all three.
• Manual verification of the full sign-in flow requires live OAuth credentials for a provider and isn't practical in this environment; the change is a minimal, isolated guard around existing logic.

🤖 Generated with Claude Code

Generated by Claude Code